Add a "Conversation width" setting (Comfortable / Wide / Full) to Appearance#63
Merged
Conversation
DragonnZhang
pushed a commit
that referenced
this pull request
Jul 6, 2026
DragonnZhang
pushed a commit
that referenced
this pull request
Jul 19, 2026
Resolve merge conflicts with main: - ChatDisplay.tsx: combine main's chat-transcript ScrollArea test id (used by the scroll-to-bottom e2e) with this PR's configurable --chat-content-max-width messages container. - docs/loop/feature-ledger.md: adopt main's canonical ledger and prepend this PR's conversation-width (#63) row.
…earance Adds a renderer-only "Conversation width" preference to Settings → Appearance → Interface, letting users widen the chat transcript and composer beyond the fixed 840px reading column — matching the width controls in Claude Desktop, ChatGPT desktop and Codex / VS Code. - New ConversationWidthProvider (localStorage `craft-conversation-width`, mirroring ReduceMotionContext) reflects the choice onto `<html>` as `data-conversation-width` and drives a `--chat-content-max-width` CSS variable (840px / 1100px / none). - ChatDisplay transcript container and ChatInputZone read the variable via `max-width: var(--chat-content-max-width, 840px)`; the fallback leaves the shared web viewer unchanged and compact/popover embeddings untouched. - Segmented control in the Appearance Interface section; adds an optional `testId` to SettingsSegmentedControl for e2e targeting. - 5 new i18n keys across all 7 locales. - CDP assertion drives the real Settings UI, cycling all three options and asserting the radio state, `<html>` attribute, computed CSS variable and persisted localStorage value. Closes #62
DragonnZhang
force-pushed
the
loop/conversation-width
branch
from
July 19, 2026 16:57
2bd2908 to
c4ad5bf
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #62
What & why
OpenWork rendered the chat transcript and the composer inside a single fixed
reading column —
CHAT_LAYOUT.maxWidth=max-w-[840px]— with no way to changeit. On large/ultrawide displays that wastes most of the window, and code-heavy
conversations (wide diffs, long tool output, tables) get needlessly wrapped.
Comparable desktop clients all expose this: Claude Desktop (wider chat),
ChatGPT desktop (chat width), Codex / VS Code (content width). This adds
the same affordance to OpenWork's Appearance page.
Changes
context/ConversationWidthContext.tsx— new renderer-only preference(
comfortable|wide|full), persisted inlocalStorage(
craft-conversation-width), mirroring the mergedReduceMotionContext(Add a "Reduce motion" accessibility setting to Appearance #51). It reflects the choice onto
<html>asdata-conversation-widthanddrives a CSS custom property
--chat-content-max-width(840px/1100px/none).ChatDisplay.tsx/ChatInputZone.tsx— the transcript container and thecomposer now read
max-width: var(--chat-content-max-width, 840px). The840pxfallback means the shared web viewer (packages/ui) andcompact/popover embeddings are untouched.
AppearanceSettingsPage.tsx— a segmented control in the Interfacesection, right below "Reduce motion".
SettingsSegmentedControl.tsx— small, backward-compatibletestIdprop(group + per-option
data-testid) for e2e targeting.local-storage.ts— newconversationWidthkey.en,zh-Hans,de,es,ja,hu,pl).Frontend-only — no qwen-code backend change.
Verification (DoD)
bun run typecheck:all— my files clean; zero-delta vsmain(identicalpre-existing error set).
bun test— zero-delta vsmain(56-failure baseline set byte-identical;i18n locale-parity outcomes unchanged).
bun run electron:build:renderer— ✅ builds (all changed code is renderer +locales).
e2e/assertions/conversation-width.assert.ts— drives the realSettings → Appearance UI, cycles all three options, and asserts for each: the
radio
aria-checkedstate, thedata-conversation-widthattribute on<html>,the computed
--chat-content-max-widthCSS variable (840px/1100px/none),and the persisted
localStoragevalue — proving it applies and reverts.Environment note: the CDP assertion could not be executed in this
sandbox — outbound egress returns
403for the Electron binary download andfor the
libsignal-node/whiskeysockets/eslint-configgit-tarball deps, soelectron:build:main, the fullbun run buildlint step, and launching Electronall fail before the app starts. These are pre-existing environment blockers
(the same egress limit recorded for the merged #51), not regressions from this
change. The assertion mirrors the merged reduce-motion assertion's exact CDP API
and is ready to run in CI where the Electron binary is available.
Generated by Claude Code